REMARKS 

Reconsideration of the above-identified application, as amended, is respectfully 

requested. 

In a first instance, a minor informality is being corrected on page 2 of the 
originally filed specification as per the Examiner's request. Further, Claim 50 is being canceled 
herein without prejudice. 

In the Office Action of July 25, 2007, now a Final Rejection, the Examiner 
rejected Claims 2-4, 6-20, 22-36, and 38-50 under 35 U.S.C. § 103(a), as being allegedly 
unpatentable over Applicants Admitted Prior Art ("AAPA") in view of Li et al. (U.S. Patent No. 
6,529,508) (hereinafter "Li"). 

Applicants respectfully disagree in view of the clarifying amendments provided 

herein. 

As a preliminary matter, applicants cancel Claims 4, 20, and 36 without prejudice, 
and wholly incorporate the subject matter thereof in respective amended independent Claims 49, 
17 and 33. Thus, the subject matter of Claims 49, 17 and 33 set forth further novel aspects of the 
invention that are neither taught nor suggested by the AAPA whether taken alone or in 
combination with Li. That is: the implementation of a data structure (element 600, Fig. 6) 
having a flag that is queried at run time to indicate if any rules exist which include Layer 4 
information (TCP Rules), and instructions on how to process fragmented frames. This flag is 
queried at run time to indicate presence of any pre-defined transfer control protocol (TCP) rules 
to apply and is used by the classifier algorithm to determine if special action must be taken when 
TCP rules are present. Additionally added to the claims is one result of performing multifield 
classification of the received fragment in the forwarding platform if the one queried flag 
indicates no TCP rules to apply . 
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Applciants' further amend Claims 49, 17 and 33 to set forth the further important 
aspect of the invention, namely, how the received fragment's fragmentation characteristics are to 
be applied when performing the multifield classification. That is, Claims 49, 17 and 33 are being 
amended to set forth the performing multifield classification of the received fragment by 
matching the key to a rule out of a plurality of rules, the rule comprising a plurality of fields 
including at least a first field comprising a first fragmented flag (FRAG) for specifying if this 
rule should match fragmented frames, non-fragmented frames, or both; and a second field 
comprising a not subsequent fragment flag (NO SUBS) in the rule key specifying whether this 
rule should match only non-fragmented frames including a first fragment of a fragmented frame, 
or is to be matched only to subsequent fragments of a fragmented frame . Thus, this amendment 
clarifies the novel aspect of providing two new flags to the rules key format whereby the first 
and second fields specify whether the received fragment's fragmentation characteristics are to be 
applied when performing the multifield classification. 

Respectfully, no new matter is being entered by this amendment as full support is 
found in the specification at page 22, line 21 to page 24, line 6 and in connection with Fig. 7 of 
the present specification. Moreover, the Examiner has already had full opportunity to search 
Claims 1 1, 27 and 43 which set forth the implementation of the first fragmented flag (FRAG) 
and second fragmented flag (NO SUBS) and thus, no new issues are believed to be raised by this 
amendment. 

By provision of these fields (flags) in the rule key, a user is enabled to create rules 
with keys that take into account the frame's fragmentation characteristics. The first flag (FRAG) 
flag in the rule key specifies if this rule should match fragmented frames, non-fragmented 
frames, or both (don't care). The second (NO SUBS) flag in the key specifies if this rule should 
or should not match subsequent fragments, or should match either (don't care). Thus, for 
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example, a TRUE value means that the rule should match only non-fragmented frames, and the first 
fragment of a fragmented frame, and a FALSE value means it should only match subsequent 
fragments of a fragmented frame. 

As mentioned in detail in the specification (see Fig. 1 1 of the present 
specification) these flags can be used to produces the following "interesting" meanings to match 
frames that are: Both Fragmented and non-fragmented; Non-fragmented only; Non-fragmented, or 
first fragment (of a fragmented frame); Fragmented only (first and subsequent) or Subsequent 
fragments only. Thus, accordingly, action data can be applied to frames with the frame's 
fragmentation characteristics taken into consideration. 

Amended Claims 49, 17 and 33, it is respectfully submitted, is clearly patentably 
distinct over the cited combination of AAPA and Li. 

Respectfully Claims 17, 33 and 49 as amended herein, are patentable over the 
combination of AAPA and the cited Li reference for the following reasons: 

1) First of all, the AAPA and Li whether taken alone or in combination do not address 
teach or suggest the received fragment preprocessing step which comprises querying 
a data structure that comprises one or more flags, with one queried flag indicating 
presence of any pre-defined transfer control protocol (TCP) rules to apply and in 
response, performing multifield classification of the received fragment in the 
forwarding platform if said one queried flag indicates no TCP rules to apply; . 

2) Nor do the AAPA and Li whether taken alone or in combination teach or suggest a 
step of redirecting or discarding the received fragment from the forwarding platform 
if it is deterrnined that the received fragment is not to be classified at the forwarding 
platform. 
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3) Nor do the AAPA and Li whether taken alone or in combination teach or suggest a 
step of matching the key to a rule out of a plurality of rules, the rule comprising a 
plurality of fields including at least a first field comprising a first fragmented flag 
fFRAG") for specifying if this rule should match fragmented frames, non-fragmented 
frames, or both; and a second field comprising a not subsequent fragment flag fNO 
SUBS) in the rule key specifying whether this rule should match only non-fragmented 
frames including a first fragment of a fragmented frame, or is to be matched only to 
subsequent fragments of a fragmented frame . 

Respectfully, at best, AAPA teaches performing a "test" whereby the "flags" field 
1 12 and "fragment offset" field are used to test whether the received packet is a packet fragment. 
However, that is where the similarity ends because according to the prior art, as shown in Figure 
3, the packet fragment is classified according to convention techniques -the classification being 
performed being not practical for high-speed forwarding platforms (e.g., network processors). 

Moreover, in Fig. 3 of the AAPA relied upon by the Examiner, there is not even a 
hint of a preprocessing step which requires querying at run time a global data structure (Fig. 6) 
for first determining whether any TCP rules are to be applied (i.e., any rules present in the rules 
database), and if the query result is negative, immediately perform classifier processing. 

Moreover, in Fig. 3 of the AAPA relied upon by the Examiner, there is not even a 
hin t of providing two new rule key flags used when performing multifield classification of the 
received fragment by matching the key to a rule out of a plurality of rules, the rule comprising a 
plurality of fields including at least a first field comprising a first fragmented flag (FRAG) for 
specifying if this rule should match fragmented frames, non-fragmented frames, or both; and a 
second field comprising a not subsequent fragment flag (NO SUBS) in the rule key specifying 
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whether this rule should match only non-fragmented frames including a first fragment of a 
fragmented frame, or is to be matched only to subsequent fragments of a fragmented frame, which 
enables action data to be applied to frames with the frame's fragmentation characteristics taken 
into consideration. 



Li is not helpful in this regard. First of all, Li's "key" used in packet classification 



as described in col. 7, lines 27-59 of Li does not address whether the packet is a fragment or not 
(i.e., Li is not directed to packet fragment handling). 



Having not made a prima facie case of obviousness, the Examiner is respectfully 



requested to withdraw the rejection of at least amended Claims 17, 33 and 49 under 35 U.S.C. 
§ 103(a) and withdraw the rejection of all remaining claims dependent therefrom. 



In view of the foregoing remarks herein, it is respectfully submitted that this 



application is in condition for allowance. Accordingly, it is respectfully requested that this 
application be allowed and a Notice of Allowance be issued. If the Examiner believes that a 
telephone conference with the Applicants' attorneys would be advantageous to the disposition of 
this case, the Examiner is requested to telephone the undersigned, Applicants' attorney, at the 
following telephone number: (516) 742-4343. 



Scully, Scott, Murphy & Presser, P.C. 
400 Garden City Plaza, Suite 300 
Garden City, New York 11530 
(516)742-4343 

SF:gc 



Respectfully submitted, 




Steven Fischman 
Registration No.: 34,594 
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